COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	/SUBJECT
C00007 00003	/SUBJECT
C00011 00004	/subject
C00017 ENDMK
C⊗;
/SUBJECT
common-lisp-object-system
Altering Generic Functions

It seems there are three proposals for the primitives used for modifying
generic functions. I will refer to the parts of generic functions as
`facets.'  Assuming that all of the facets discussed in the current draft
specification are accepted, the modifiable facets are:
argument-precedence-order, generic-function-class, interface,
method-arguments, method-class, and method-combination-type.  Here are the
proposals:

1. There is a series of facet accessors, each accessor naming a SETFable
place.

2. There is a function named MODIFY-GENERIC-FUNCTION that takes a required
generic function argument followed by the same keyword arguments that
MAKE-GENERIC-FUNCTION accepts.  Furthermore, there is a function, possibly
named GENERIC-FUNCTION-FACETS, that returns six values, one for each
modifiable facet.

3. MAKE-GENERIC-FUNCTION accepts a keyword argument that is a generic
function to be updated from the other arguments. In addition there is
function, possibly named GENERIC-FUNCTION-FACETS, that returns six values,
one for each modifiable facet.

Here are the advantages and disadvantages of each, as I see them.

1. There are six new function names, one for each modifiable facet.
Because these functions simply are accessors to parts of some larger
object, this requires knowing about many function names. Changing the
facets, though, only requires knowing that the accessors are SETFable.

2. One new function is added, but with six keywords to remember. These
keywords are the same as the keywords for MAKE-GENERIC-FUNCTION, so the
additional cognitive overhead is low. There is a new function that returns
six values, and the order of the values will be difficult or impossible to
remember.

3. This option is very much like number 2, but the name of the function is
misleading - one is not making a generic function, one is altering some of
its characteristics.

Contrasting option 1 with options 2 and 3, the choices we face are similar
to those faced earlier with the sequence functions in Common Lisp.  The
two basic choices were: a large series of independent functions or a
smaller series with a set of keyword arguments. The Common Lisp designers
chose the keyword route.

The analogy breaks down here because we require a complex informational
function, GENERIC-FUNCTION-FACETS, which is needed to find out the current
facets of a generic function. Without it, it is not possible to modify
programmatically some facets of one generic function to be the same as
those of another.

Therefore, I favor option 1.

Larry Masinter suggsted something interesting. Generic functions could be
defined to be instances of a generic-function class. Therefore, these six
facets are simply `slots' defined by the generic-function class; instances
have these `slots,' and they are naturally SETFable.

			-rpg-
/SUBJECT
common-lisp-object-system
Altering Things

Larry's comments bring up the issue of how far we want to take the
meta-class concept in this specification. The standard-type-classes have a
different meta-class from those of DEFCLASS. DEFCLASS is somewhat like
DEFSTRUCT in that it defines an instance structure with slots in which
values may be stored.

As Larry points out, generic functions can made instances of a generic
function class whose meta-class directs the creation of `slot accessors
and updators' that modify facets of the precise sort thing that generic
functions happen to be in some implementation.

Thinking of these facets as slots is quaint, in the same way that one can
think of the `mantissa' and `exponent' as slots in a floating-point number.
Of course, with meta-objects this can done. I say this is `quaint' because
it is promulgating a misnomer of sorts, the misnomer of referring to the
subparts of eveything as `slots.' 

It is the class of CLASS that defines `slots.' It would be the class of
FLOATING-POINT-CLASS that would define `mantissa' and `exponent.' We would
be taking the terminolgy specific to DEFCLASS-style classes and misapplying
it in talking about floating-point numbers.

We will recommend to X3J13 that they split DEFSTRUCT into DEFCLASS and
DEFRECORD, which makes sense. When we try to think of floating-point
numbers as instances of classes, and when we break floating-point numbers
into mantissas and exponents, we are making the classes into
record-structure-defining objects. Similarly, thinking of generic functions
as objects whose `slots' are SETFable, we are using the DEFCLASS terminology
to impose some record structure on top of generic functions.

Smalltalk takes seriously the approach I'm hinting at, and possibly we
want to take it seriously as well. The simple class CLASS approach we in
fact take is a simplfication of the whole-hog, Smalltalk approach.

			-rpg-
/subject
skeene@symbolics, lgd
Changes to CONCEPTS

Ladies:

I've backed up the December 24 version of CONCEPTS as CONCEP.6, so there
is no need to worry about the changes I'm making. This message contains
my changes and why I made them.

The document currently says:

``The primitive entities of Common Lisp are called {\bit objects}.''

I didn't change this, but it is awkward, because people will say ``no they
aren't.'' We are trying to say that if and when CLOS is accepted, then
we will be changing our terminology so that this statement will be true.
I want to find a way to say this in such a way that people will see that
existing, ordinary Common Lisp entities are considered `objects' as
well as new ones added by this standard.

On Generic Functions:

I decided to state up front that a generic function is a function and to
later state that ``generic functions are objects that may be specialized to
provide class-specific operations....''

I still don't like this because there is no way for a reader to understand the
jargon of ``a function being specialized to provide class-specific operations.''
This concept has to be spelled out. I added a sentence before this mysterious
one that connects generic functions and methods, in an attempt to de-mystify
this paragraph.

The old document says:

``When a generic function is invoked, the implementation of the generic
function consists of a set of methods that are executed in a certain
order.''

The terminology ``the implementation of the generic function consists''
is confusing and imprecise to the first-time reader. I've re-written this
to use the terminology ``behavior'' to simplify the reader's life.

The old document said:

``Like other objects, all classes are themselves instances of other classes.''

This leaves out the possibility that a class could be an instance of itself,
a possibility we do not want to preclude.

The old document said:

``Less formally, we will also use the term metaclass to refer to....''

I don't think we're being less formal, and I don't think this adverbial
phrase attaches well to anything. I've changed this to read:

``Although it is less precise, we will ....''

And it is dropping the most precise possible terminology in favor of
a less verbose, more understandable terminology that we do when we misuse
``metaclass.''

I've re-worded other parts of this paragraph to use ``instances of'' in the
right places, so at least this paragraph uses the terms precisely.

I started to use the direct superclass/superclass etc terminology because
it seems like components, etc, are excessive.

I added more discussion about the local precedence order and the class
precedence list with respect to the lattice earlier on to pave the
way for later discussion.

Changed ``default value'' to ``default value form'' in the description of
DEFCLASS.

I changed this:

``\item{\bull} Requesting that methods
be automatically generated for reading or accessing one or more slots. ''

to this:

``\item{\bull} Requesting that methods for appropriately named generic functions
be automatically generated for reading or accessing one or more slots.''

Because the first one was inaccurate.

I changed the terminology ``implementation varies'' to something a little
more precise but a little less colorful. I also changed, slightly, the
wording of the role of DEFGENERIC - it is now played down a bit more than
it was.

I put in my description of computing the class precedence list to see
how it read.

			-rpg-